Anonymous sysadmin of remote systems.

Introduction[edit]

Warning[edit]

Remote administration of any system should be considered a potential anonymity hazard, since it is not under the user's physical protection and could be compromised. All activities, all programs, everything should be assumed to be monitored by the host of the server (VPS, dedicated server, etc.).

Although counter-intuitive, it is necessary to follow all relevant recommendations in the Surfing Posting Blogging chapter to stay safe:

Beware of Keystroke and Mouse Fingerprinting.
Beware of Stylometry.
Beware of difficulties in paying anonymously, see Money.

At a minimum, check the connection is encrypted / authenticated, because Virtual Network Computing (VNC) by default is unencrypted / unauthenticated. Possible methods:

Perhaps by tunneling VNC through SSH;
Running VNC through a Tor Onion Service;
Using both SSH and an Onion Service, for stronger encryption and authentication; or
Onion Services Authentication.

In case remote servers are exclusively available over .onion: Might get locked out due to Onion Services Reliability Issues.

SSH has a lower attack surface than VNC (for example Mouse Fingerprinting is not possible against simple SSH (terminal only, no X11 forwarding).

UDP[edit]

It is suggested to utilize software that does not require the User Datagram Protocol (UDP), for the following reason.

The Tor software does not support UDP. The feature request UDP over Tor was created in 2013 and closed as won't fix by upstream, The Tor Project in 2018. It is therefore highly unlikely that the UDP over Tor feature will ever be implemented. This is unspecific to Whonix.

Tor provides a DnsPort but that is unrelated.

If UDP is urgently required in Whonix, a limited workaround is provided. For the most secure method, see Tunnel UDP over Tor.

Remmina[edit]

It is possible to remotely administer any operating system with GNU/Linux by using the Remmina desktop client. Remmina supports multiple network protocols, including RDP, VNC, SPICE, NX, XDMCP, SSH and EXEC. For an overview of Remmina features, see here.

Note there are two separate Debian packages:

remmina: the main GTK+ application.
remmina-plugins: a set of plugins to support various network protocols.

Install package(s) remmina following these instructions

Platform specific notice.

Non-Qubes-Whonix: No special notice.
Qubes-Whonix: In Template.

Update the package lists and upgrade the system .

sudo apt update && sudo apt full-upgrade

Install the remmina package(s).

Using apt command line --no-install-recommends option is in most cases optional.

sudo apt install --no-install-recommends remmina

Platform specific notice.

Non-Qubes-Whonix: No special notice.
Qubes-Whonix: Shut down Template and restart App Qubes based on it as per Qubes Template Modification .

Done.

The procedure of installing package(s) remmina is complete.

If you are interested in using Remmina, please first search the forums for this topic: https://forums.whonix.org/search?q=remmina

SSH into Whonix[edit]

Introduction[edit]

It is possible to install an SSH server on either Whonix-Gateway and/or Whonix-Workstation^™ and make it accessible through an anonymous onion service.

SSH into Whonix-Gateway[edit]

1. Update the package lists and install necessary software.

sudo apt update

Install the openssh-server package.

sudo apt install --no-install-recommends openssh-server

2. Optionally harden SSH.

3. Make necessary Whonix-Gateway^™ adjustments.

Open file /usr/local/etc/torrc.d/50_user.conf in a text editor of your choice with sudoedit.

If you are using Qubes-Whonix^™, complete the following steps.

Qubes App Launcher (blue/grey "Q") → Whonix-Gateway^™ ProxyVM (commonly named sys-whonix) → Tor User Config (Torrc)

If you are using a graphical Whonix-Gateway, complete the following steps.

Start Menu → Applications → Settings → /usr/local/etc/torrc.d/50_user.conf

If you are using a terminal-only Whonix-Gateway, complete the following steps. sudoedit /usr/local/etc/torrc.d/50_user.conf

Add.

HiddenServiceDir /var/lib/tor/gateway_ssh_service/ HiddenServicePort 22 127.0.0.1:22 HiddenServiceVersion 3

Save.

4. Reload Tor.

After changing Tor configuration, Tor must be reloaded for changes to take effect.

Note: If Tor does not connect after completing all these steps, then a user mistake is the most likely explanation. Recheck /usr/local/etc/torrc.d/50_user.conf and repeat the steps outlined in the sections above. If Tor then connects successfully, all the necessary changes have been made.

If you are using Qubes-Whonix^™, complete the following steps.

Qubes App Launcher (blue/grey "Q") → Whonix-Gateway^™ ProxyVM (commonly named 'sys-whonix') → Reload Tor

If you are using a graphical Whonix-Gateway, complete the following steps.

Start Menu → Applications → Settings → Reload Tor

If you are using a terminal-only Whonix-Gateway, click HERE for instructions.

Complete the following steps.

Reload Tor.

sudo service tor@default reload

Check Tor's daemon status.

sudo service tor@default status

It should include a a message saying.

Active: active (running) since ...

In case of issues, try the following debugging steps.

Check Tor's config.

sudo -u debian-tor tor --verify-config

The output should be similar to the following.

Sep 17 17:40:41.416 [notice] Read configuration file "/usr/local/etc/torrc.d/50_user.conf".
Configuration was valid

5. Retrieve the Tor onion service url.

sudo cat /var/lib/tor/gateway_ssh_service/hostname

Reminder: Always backup the onion service key. This is necessary in order to restore it on another machine, on a newer Whonix-Gateway^™, after HDD/SSD failure, etc. Follow the instructions below to find its location; root permission is required to access it.

/var/lib/tor/workstation_ssh_service/hs_ed25519_secret_key

Qubes-Whonix^™

The following example shows how to copy the /var/lib/tor/workstation_ssh_service/hs_ed25519_secret_key from the sys-whonix VM to the vault VM (which should be started beforehand) using qvm-copy. A dialog will appear asking for the destination VM.

sudo qvm-copy /var/lib/tor/workstation_ssh_service/hs_ed25519_secret_key

When the dialog appears asking to confirm, select vault. This copies the Tor onion service private key file to the QubesIncoming folder of the vault VM.

/home/user/QubesIncoming/sys-whonix/hs_ed25519_secret_key

Consider moving the file from the QubesIncoming folder to another preferred location.

Qubes VM Manager can be used to conveniently backup the vault and/or other VMs. Please refer to the Qubes backups documentation for necessary steps to accomplish that.

Non-Qubes-Whonix

SSH into Whonix-Workstation[edit]

1. Update the package lists and install necessary software.

sudo apt update

Install the openssh-server package.

sudo apt install --no-install-recommends openssh-server

2. Optionally harden SSH.

3. Make necessary Whonix-Gateway adjustments.

Open file /usr/local/etc/torrc.d/50_user.conf in a text editor of your choice with sudoedit.

If you are using Qubes-Whonix^™, complete the following steps.

Qubes App Launcher (blue/grey "Q") → Whonix-Gateway^™ ProxyVM (commonly named sys-whonix) → Tor User Config (Torrc)

If you are using a graphical Whonix-Gateway, complete the following steps.

Start Menu → Applications → Settings → /usr/local/etc/torrc.d/50_user.conf

If you are using a terminal-only Whonix-Gateway, complete the following steps. sudoedit /usr/local/etc/torrc.d/50_user.conf

Add.

Qubes-Whonix Note: Cannot use 10.152.152.11:22. See page Onion Services for /qubes-ip.

HiddenServiceDir /var/lib/tor/workstation_ssh_service/ HiddenServicePort 22 10.152.152.11:22 HiddenServiceVersion 3

Save.

4. Reload Tor.

Reload Tor.

After changing Tor configuration, Tor must be reloaded for changes to take effect.

Note: If Tor does not connect after completing all these steps, then a user mistake is the most likely explanation. Recheck /usr/local/etc/torrc.d/50_user.conf and repeat the steps outlined in the sections above. If Tor then connects successfully, all the necessary changes have been made.

If you are using Qubes-Whonix^™, complete the following steps.

Qubes App Launcher (blue/grey "Q") → Whonix-Gateway^™ ProxyVM (commonly named 'sys-whonix') → Reload Tor

If you are using a graphical Whonix-Gateway, complete the following steps.

Start Menu → Applications → Settings → Reload Tor

If you are using a terminal-only Whonix-Gateway, click HERE for instructions.

Complete the following steps.

Reload Tor.

sudo service tor@default reload

Check Tor's daemon status.

sudo service tor@default status

It should include a a message saying.

Active: active (running) since ...

In case of issues, try the following debugging steps.

Check Tor's config.

sudo -u debian-tor tor --verify-config

The output should be similar to the following.

Sep 17 17:40:41.416 [notice] Read configuration file "/usr/local/etc/torrc.d/50_user.conf".
Configuration was valid

5. Retrieve the Tor onion service url.

sudo cat /var/lib/tor/workstation_ssh_service/hostname

Reminder: Always backup the onion service key. This is necessary in order to restore it on another machine, on a newer Whonix-Gateway^™, after HDD/SSD failure, etc. Follow the instructions below to find its location; root permission is required to access it.

/var/lib/tor/workstation_ssh_service/hs_ed25519_secret_key

Qubes-Whonix^™

The following example shows how to copy the /var/lib/tor/workstation_ssh_service/hs_ed25519_secret_key from the sys-whonix VM to the vault VM (which should be started beforehand) using qvm-copy. A dialog will appear asking for the destination VM.

sudo qvm-copy /var/lib/tor/workstation_ssh_service/hs_ed25519_secret_key

When the dialog appears asking to confirm, select vault. This copies the Tor onion service private key file to the QubesIncoming folder of the vault VM.

/home/user/QubesIncoming/sys-whonix/hs_ed25519_secret_key

Consider moving the file from the QubesIncoming folder to another preferred location.

Qubes VM Manager can be used to conveniently backup the vault and/or other VMs. Please refer to the Qubes backups documentation for necessary steps to accomplish that.

Non-Qubes-Whonix

Graphical[edit]

Introduction[edit]

It is possible to install a VNC server on either Whonix-Gateway and/or Whonix-Workstation and make it accessible through an anonymous onion service.

x2go[edit]

Installation[edit]

1. Set up SSH first as per above chapters.

This is because x2go uses SSH. x2go might be incompatible with SSH hardening. It has been reported that x2go is incompatible with password protected SSH keys but this was not investigated further or reported upstream.

2. Update the package lists and install necessary software.

Either on Whonix-Gateway or Whonix-Workstation, depending on where incoming x2go connection should be accepted.

sudo apt update

Install the x2goserver package.

sudo apt install --no-install-recommends x2goserver

Usage[edit]

In a Whonix-Workstation (remote-support-provider VM). ^[1]

1)

Install package(s) x2goclient following these instructions

Platform specific notice.

Non-Qubes-Whonix: No special notice.
Qubes-Whonix: In Template.

Update the package lists and upgrade the system .

sudo apt update && sudo apt full-upgrade

Install the x2goclient package(s).

Using apt command line --no-install-recommends option is in most cases optional.

sudo apt install --no-install-recommends x2goclient

Platform specific notice.

Non-Qubes-Whonix: No special notice.
Qubes-Whonix: Shut down Template and restart App Qubes based on it as per Qubes Template Modification .

Done.

The procedure of installing package(s) x2goclient is complete.

2) Start x2goclient.

As user. Run x2goclient.

host: the onion v3 domain
login: the user name such as user
password: the user login password such as changeme
session type: connect to local desktop
media -> disable client side printing support
media -> disable sound support
settings for better performance
- connection -> connection speed -> WAN
- connection -> image quality 0
- connection -> method -> 8-jpeg
- feel free to experiment with these settings
OK
Click on the newly setup connection
OK

Alternatively session type terminal could be used.

Test Results[edit]

Using Non-Qubes-Whonix. All times are created with an external stopwatch and should have +/- 2 seconds human caused inaccuracy.

keypress delay: 2 seconds
maximize xfce4-terminal-emulator window: 1.5 seconds
cd /etc && ls -la: 2 seconds
clock in systray (shows seconds) update: every 1 or 2 seconds
start thunar: 5 seconds

Using Qubes / Qubes-Whonix is a lot slower, has additional challenges and is still under development, see Dev/Qubes_Remote_Support.

Qubes - SSH or VNC into Qubes dom0[edit]

Introduction[edit]

Encrypted, authenticated SSH or VNC into Qubes dom0 over an authenticated Tor onion v3 service.

Design ^[2]:

Encrypted. ^[3]
Authenticated. ^[4]
Over Tor.
Implemented using an authenticated Tor onion v3 service.
Even if Whonix on qubes-remote-support-receiver machine was compromised, the attacker will not be able to access dom0. ^[5]
The package will not be installed by default.
The design requires explicit connection initiation by the user (no any open ports, extra network connections etc before that point). And when the user initiate the connection, it requires sharing a code word with the remote party to be able to connect.
No open ports required.
No router settings changes required.
Works behind NAT.
Works over mobile networks (3G, 4G, 5G).

Instructions:

qubes-remote-support-receiver have to be applied by the person who intents to receive remote support.
qubes-remote-support-provider have to be applied by the person who intents to provide remote support.

qubes-remote-support-receiver[edit]

Security advice: Giving a third party remote support access is a very delicate permission. As with any remote support permission, the qubes-remote-support-provider could persistently compromise the qubes-remote-support-receiver with malware without the user having a chance to notice that. Learn The Importance of a Malware Free System.

1) Qubes dependency installation.

Install package qubes-remote-support-receiver-dom0 in Qubes dom0. ^[6] ^[7]

sudo qubes-dom0-update qubes-remote-support-receiver-dom0

2) Run the qubes-remote-support-receiver-start command line utility.

qubes-remote-support-receiver-start

Will show something like this (example):

wormhole_code: 9-support-concert

3) Notification.

Tell the wormhole code (for example 9-support-concert) to the person you would like to receive Qubes remote support from, i.e. the qubes-remote-support-provider.

Note: not 9-support-concert. The actual code as shown in terminal / graphical user interface.

4) To check status of remote support.

qubes-remote-support-receiver-status

5) To terminate remote support.

qubes-remote-support-receiver-stop

qubes-remote-support-provider[edit]

1) Dependency installation.

Start whonix-workstation-17 Template.

(The latter package x2goclient can be omitted from installation connecting to qubes-remote-support-receiver use of x2go (VNC) is unwanted.)

Install package(s) openssh-client x2goclient following these instructions

Platform specific notice.

Non-Qubes-Whonix: No special notice.
Qubes-Whonix: In Template.

Update the package lists and upgrade the system .

sudo apt update && sudo apt full-upgrade

Install the openssh-client x2goclient package(s).

Using apt command line --no-install-recommends option is in most cases optional.

sudo apt install --no-install-recommends openssh-client x2goclient

Platform specific notice.

Non-Qubes-Whonix: No special notice.
Qubes-Whonix: Shut down Template and restart App Qubes based on it as per Qubes Template Modification .

Done.

The procedure of installing package(s) openssh-client x2goclient is complete.

Shutdown whonix-workstation-17 Template.

2) Start virtual machine (VM).

Open a whonix-workstation-17 based VM. Recommended but optional: DispVM. This will be refereed to as qubes-remote-support-provider VM.

3) Run qubes-remote-support-provider script in qubes-remote-support-provider VM.

qubes-remote-support-provider

It is an interactive script. Read what it says. Continue by pressing enter.

4) When it says:

INFO: Install authenticated Tor onion v3 service private key with the following command in sys-whonix.
sudo sourcefile=~/QubesIncoming/disp4522/1.auth_private anon-server-to-client-install

Do as instructed in sys-whonix VM. Do not copy the command from here. Copy the command from qubes-remote-support-provider VM script output, then paste and run in sys-whonix VM. Then press enter to continue in qubes-remote-support-provider VM.

5) Done.

Should now be connected by SSH.

6) Optional: Connect by graphical remote support (x2go).

As per instructions below.

x2goclient[edit]

Broken until upstream fix for issue x2goagent 3.5.99.26 crashes on connect flows to Qubes dom0. TODO: Was fixed?

In a Whonix-Workstation (remote-support-provider VM).

1) Start x2goclient.

As user. Run x2goclient.

2) x2goclient settings

session tab
- host: the onion v3 domain
- enable Try auto login (via SSH agent or default SSH key)
- session type: connect to local desktop
media tab
- media -> disable client side printing support
- media -> disable sound support
connection tab
- These are optional settings for better performance. Feel free to experiment with these settings.
- connection -> connection speed -> WAN
- connection -> image quality 0
- connection -> method -> 8-jpeg
OK
Click on the newly setup connection
OK

Alternatively session type terminal could be used.

If you can only see a black screen, the the desktop might be locked (xscreensaver). Any mouse movement or any keypress should prompt for password.

Not required:

login: not required
password: not required

printout[edit]

Qubes Remote Support Receiver[edit]

qubes-remote-support-receiver-start

INFO: Starting Qubes Remote Support Receiver.
INFO: This tool is supposed to be run by those who wish to receive remote support.
INFO: Setting up... This will take a moment...
INFO: Remote support archive file '/tmp/tmp.Yfv3ehL6ZJ/remote-support-keys.tar.gz' was successfully created.
INFO: (That file allows a Qubes Remote Support Provider to connect to this machine.)
INFO: (No need to do anything with that file.)
INFO: Starting the file transfer tool magic-wormhole... This will take a moment...
INFO: File transfer too magic-wormhole successfully started.
INFO: The next line will show a wormhole code phrase. Send the code to the Qubes Remote Support Provider. Once the the Qubes Remote Support Provider acknowledged receipt, just wait.
wormhole_code: 9-one-two-three-four
INFO: The Qubes Remote Support Provider successfully received the remote support archive file and is now able to establish remote support.
INFO: This can take up to 10 minutes.

INFO: Should you wish to stop this Qubes Remote Support Session, please run:
qubes-remote-support-receiver-stop

INFO: This tool will exit now and there is nothing else to do besides waiting.
INFO: Success.

qubes-remote-support-receiver-status

● sshd.service - OpenSSH server daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
     Active: active (running) since Sat 2021-02-13 06:49:51 EST; 3 weeks 3 days ago
[...]
Hint: Some lines were ellipsized, use -l to show in full.
INFO: /etc/qubes-rpc/policy/qubes.ConnectTCP+22 looks OK.
qvm-check: {{project_name_gateway_vm}}: running
INFO: VM '{{project_name_gateway_vm}}' already running, ok.
___ qubes-whonix-remote-support.service - Qubes-Whonix Remote Support
   Loaded: loaded (/lib/systemd/system/qubes-whonix-remote-support.service; disabled; vendor preset: disabled)
   Active: active (running) since Tue 2021-03-09 13:51:30 UTC; 9min ago
[...]
___ tor@default.service - Anonymizing overlay network for TCP
   Loaded: loaded (/lib/systemd/system/tor@default.service; enabled-runtime; vendor preset: enabled)
[...]
   Active: active (running) since Tue 2021-03-09 13:43:23 UTC; 17min ago
[...]
INFO: Success.

qubes-remote-support-receiver-stop

INFO: sshd was previously running, therefore not stopping it, ok.
INFO: VM '{{project_name_gateway_vm}}' already running, ok.
INFO: Success, remote support received has been turned off.

Qubes Remote Support Provider[edit]

qubes-remote-support-provider

INFO: Starting Qubes Remote Support Provider.
INFO: This tool is supposed to be run by those who wish to provide remote support.
INFO: Setting up... This will take a moment...
INFO: Ask the remote support receiver for the wormhole code phrase and enter it below.
Enter receive wormhole code: 9-one-two-three-four
 (note: you can use <Tab> to complete words)
Receiving file (814 Bytes) into: remote-support-keys.tar.gz
ok? (y/N): y
Receiving (->relay:tcp:magic-wormhole-transit.debian.net:4001)..
100%|████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 814/814 [00:00<00:00, 3.82MB/s]
Received file written to remote-support-keys.tar.gz
INFO: Success, received remote support archive file '/tmp/tmp.ZTe9baxU6Z/remote-support-keys.tar.gz'.
INFO: (That file allows a Qubes Remote Support Provider to connect to this machine.)
INFO: (No need to do anything with that file.)
INFO: Setting up... This will take a moment...

Success. Please continue as instructed below.

INFO: To avoid confusion, it is advised your delete folder ~/QubesIncoming in {{project_name_gateway_vm}} if it exists. In most cases no such folder exists.
INFO: If there is nothing you need to backup, you could run the following command in {{project_name_gateway_vm}}:

rm -rf ~/QubesIncoming

INFO: When done, press enter to continue.

INFO: Will ask to copy 1.auth_private to {{project_name_gateway_vm}}.
INFO: When Qubes dom0 asks, answer to copy to {{project_name_gateway_vm}}.
INFO: Press enter to continue.

sent 0/1 KB

INFO: Install authenticated Tor onion v3 service private key by running the following command in {{project_name_gateway_vm}}:

sudo sourcefile=~/QubesIncoming/disp2887/1.auth_private anon-server-to-client-install

INFO: When done, press enter to continue.

INFO: Do you want to SSH to 'xxx.onion'?
INFO: Press enter to continue.

INFO: Trying SSH...
INFO: Will keep trying to run the following command...
ssh 'xxx.onion'
INFO: This can take up to 10 minutes.
Last login: Tue Mar  9 08:49:28 2021 from xx.xx.xx.x
[user@dom0 ~]$

Test Results[edit]

Running a simple command such as ls -la takes 1 second until results are drawn.
There is an 1 seconds delay between a keypress on inside remote-support-provider VM until it gets visible in the remote terminal.
Click Xfce start menu: 2 seconds
clock in systray (shows seconds) update: every 1 or 2 seconds
There is a bug where I have no idea if caused by Qubes or x2go or a combination of it. When pressing any key it sometimes happen that this key is auto-repeat "jammed". I.e. "a" becomes "aaaaaaaaaaaaaaa" (no exact counting).

Help Wanted[edit]

Please contribute by helping to create full working instructions in Whonix! See:

Future Research[edit]

[1] comparing vnc, nx(x2go) and spice. VNC sends the least amount of data. nx has a stable perf irrelevant of bandwidth conditions however one disadvantage I came across was it is heavily tied to X11 and therefore not future proof. https://bbs.archlinux.org/viewtopic.php?id=225765
[1] https://www.diva-portal.org/smash/get/diva2:530960/FULLTEXT01.pdf
VNC perf depends heavily on implementation details. TigerVNC is better than realvnc, but Remmina is commented to be better than tiger. "A 2010 reviewer found the TigerVNC product "much faster than Vinagre https://en.wikipedia.org/wiki/Vinagre but not quite as responsive as Remmina https://en.wikipedia.org/wiki/Remmina https://en.wikipedia.org/wiki/TigerVNC "
Tiger can be further optimized for constrained environments by ratcheting up the compression and lowering the jpeg quality. NB turbo isn't in Debian and it seems geared towards 3D usage. https://turbovnc.org/About/TigerVNC

Footnotes[edit]

↑ Or any other system with transparent torification. It cannot be easily made to work using socksifier torsocks.
↑
- https://github.com/QubesOS/qubes-issues/issues/6364#issuecomment-767166712
- Dev/Qubes Remote Support
↑ Thanks to encryption provided by Tor onion v3 and SSH.
↑ Thanks to authentication provided by Tor onion v3, onion authentication and SSH.
↑ Thanks to encryption/authentication provided by SSH.

Public/private keys for SSH are generated in Qubes dom0 by qubes-remote-support-receiver. At no point, any Whonix VM on qubes-remote-support-receiver has access to any SSH keys.

SSH keys are transferred from qubes-remote-support-receiver to qubes-remote-support-provider using magic-wormhole tool over Tor.
↑ https://github.com/QubesOS/qubes-remote-support
↑
- https://github.com/QubesOS/qubes-issues/issues/6364
- https://github.com/QubesOS/updates-status/issues/2353

Whonix

The most watertight privacy operating system in the world.

Dark mode

Supported by Power Up Privacy

Whonix is proudly supported until 2025 by Power Up Privacy, a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place. (Strictly subject to our sponsorship policy.)

At Whonix we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint

2012- 2024 ENCRYPTED SUPPORT LP

Your support makes
all the difference!

We believe security software like Whonix needs to remain open source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!

[1] Or any other system with transparent torification. It cannot be easily made to work using socksifier torsocks.

[2] 
https://github.com/QubesOS/qubes-issues/issues/6364#issuecomment-767166712

Dev/Qubes Remote Support

[3] ttps://github.com/QubesOS/qubes-issues/issues/6364#issuecomment-767166712

[4] Dev/Qubes Remote Support

[3] Thanks to encryption provided by Tor onion v3 and SSH.

[4] Thanks to authentication provided by Tor onion v3, onion authentication and SSH.

[5] Thanks to encryption/authentication provided by SSH.

Public/private keys for SSH are generated in Qubes dom0 by qubes-remote-support-receiver. At no point, any Whonix VM on qubes-remote-support-receiver has access to any SSH keys.

SSH keys are transferred from qubes-remote-support-receiver to qubes-remote-support-provider using magic-wormhole tool over Tor.

[6] ttps://github.com/QubesOS/qubes-remote-support

[7] 
https://github.com/QubesOS/qubes-issues/issues/6364

https://github.com/QubesOS/updates-status/issues/2353

[10] ttps://github.com/QubesOS/qubes-issues/issues/6364

[11] ttps://github.com/QubesOS/updates-status/issues/2353

[1]

[2]

[3]

[4]

[5]

[6]

[7]

Remote Administration

Contents

Introduction[edit]

Warning[edit]

UDP[edit]

Remmina[edit]

SSH into Whonix[edit]

Introduction[edit]

SSH into Whonix-Gateway[edit]

SSH into Whonix-Workstation[edit]

Graphical[edit]

Introduction[edit]

x2go[edit]

Installation[edit]

Usage[edit]

Test Results[edit]

Qubes - SSH or VNC into Qubes dom0[edit]

Introduction[edit]

qubes-remote-support-receiver[edit]

qubes-remote-support-provider[edit]

x2goclient[edit]

printout[edit]

Qubes Remote Support Receiver[edit]

Qubes Remote Support Provider[edit]

Test Results[edit]

See Also[edit]

Help Wanted[edit]

Future Research[edit]

Footnotes[edit]

Navigation menu

Remote Administration

Introduction[edit]

Warning[edit]

UDP[edit]

Remmina[edit]

SSH into Whonix[edit]

Introduction[edit]

SSH into Whonix-Gateway[edit]

SSH into Whonix-Workstation[edit]

Graphical[edit]

Introduction[edit]

x2go[edit]

Installation[edit]

Usage[edit]

Test Results[edit]

Qubes - SSH or VNC into Qubes dom0[edit]

Introduction[edit]

qubes-remote-support-receiver[edit]

qubes-remote-support-provider[edit]

x2goclient[edit]

printout[edit]

Qubes Remote Support Receiver[edit]

Qubes Remote Support Provider[edit]

Test Results[edit]

See Also[edit]

Help Wanted[edit]

Future Research[edit]

Footnotes[edit]

Navigation menu

Search